Summary

Given a monorepo setup under git version control, we saw jest --watch commands take significantly longer in a Docker container host mount (rw:cached) than when on the host directly. Tracked the issue down to the fact that git and hg command used to determine lastCommit changes were traversing the entire repository, and not just paths specified in the Jest config roots values. Given the mounted container latency, things like basic lstat gathering be intensive in a large repository. The roots we had specified are rather shallow themselves and only contain things we want to test with Jest. When limiting the scope of the git command to just the roots paths, we saw change determination drop from 2.5m to 3s in our container.

This implementation seem to align more closely with the roots documentation which indicates:

A list of paths to directories that Jest should use to search for files in.

It did seem a little unexpected that Jest would be traversing our entire repo.

Test plan

Specs have been added for new functionality a build from this fork is currently being used in multiple environments.

For reference, here is our Jest configuration:

"jest": {
    "rootDir": "spec/puppeteer",
    "testPathIgnorePatterns": [
        "__image_snapshots__"
    ],
    "testMatch": [
        "<rootDir>/*_screenshot_spec.js"
    ],
    "reporters": [
        "default",
        [
            "jest-junit",
            {
                "output": "test-results/puppeteer.xml"
            }
        ]
    ],
    "verbose": true
}

The spec/puppeteer subdirectory contains only a handful of files whereas the project containing the package.json itself is quite expansive. A similar environment staging is probably easily recreated.